This function actually does let you pass null to it, and will just "do nothing" to the Writer object. In that case there is nothing to serialize but it does not complain about that.

Telling PHPstan that null is possible, stops it complaining about elseif (is_object($value)) below - it now understands that $value could be nullor an object at that point.

What is the "good thing" to do for situations like this?
An input parameter allows some "complicated" set of inputs/types.
It is too complicated to be expressed in the actual PHP function declaration.
So at run-time PHP will actually let the caller pass anything in the parameter.
The function code checks the input parameter, doing "the expected thing" to process inputs of each of the "officially allowed" inputs.

The function code throws an exception if the passed-in value is not one of the "officially allowed" inputs. But PHPstan is going to consider that that is "useless" code.

For this defensive style of programming you should set treatPhpDocTypesAsCertain: false in the PHPStan config

If I do that, it will apply to all the code. So I just added the entry to ignoreErrors

sure, if you are fine with ignoring the error thats fine, too.

Array keys (name) have to be int or string. And we tested for is_int above. So PHPstan correctly reports that the is_string check here is useless.

But as a result of looking into this, I don't understand why PHPstan allows the code at line 193, elseif (is_string($name)), because we know that $name must be a string at that point.
And the else at line 198 looks useless. The exception can never be thrown, because PHP only allows array keys of type int or string, so we can never get to that InvalidArgumentException

array keys are pretty magic and some auto-conversions are going on in the background in php-src (some strings are turned into numbers)

https://3v4l.org/amqMg

array keys are pretty magic and some auto-conversions are going on in the background in php-src (some strings are turned into numbers)

If someone tries to have a key $someArray['42'] then PHP is going to treat it as $someArray[42], and the code (both before and after this PR) is going to go into the is_int() case a few lines up. So that's a "feature" of PHP. And I don't think that there will be any callers who actually want/need to force a string key that is an ASCII decimal number.

This message is emitted because of line 204

    } elseif (!is_null($value)) {
        throw new \InvalidArgumentException('The writer cannot serialize values of type: '.gettype($value));
    }

The if-else cases already processed all the possible types according to the type declaration of $value except for null. So PHPstan thinks that $value must be null at that point, and so we can never get that InvalidArgumentException

But someone could pass some other unusual type of value to standardSerializer The type would not fit with the PHPdoc declared set of types, but the PHP run-time is not going to complain. So "catch-all" exceptions like that are actually valid/useful.

It's better not to tell the test code what $result should be.
The test code does asserts itself to check that.